Obed Owusu
APIM · Logic Apps · Service Bus · Dynamics 365 · Azure Monitor

Azure Enterprise Integration Platform. API gateway, Logic Apps, queue resilience and operational runbooks.

A production-style Azure platform operations project built around Azure API Management, Logic Apps, Dynamics 365 / Dataverse, Service Bus and Azure Monitor. The project proves the integration can be built, monitored, broken, investigated, recovered and documented like a real cloud platform.

Azure API ManagementLogic Apps Producer + ConsumerService Bus QueueDynamics 365 / DataverseAzure Monitor AlertsBreak/Fix IncidentsOperational Runbooks
Engineering deep dive →
APIM 202 accepted validatedService Bus backlog reached 45 active messagesConsumer parse failure fixed and documented
SectionsOverviewArchitectureBreak/FixMonitoringGalleryRunbooksLessons
Architecture diagram for Azure Integration Operations Lab
↗View GitHub profile
Azure Integration Operations Lab
APIM GatewayQueue Recovery
Architecture snapshotEvidence in gallery below.
APIM Test Console / API Client
→ Azure API Management
→ Producer Logic App
→ Dynamics 365 / Dataverse Accounts
→ Service Bus Queue
→ Consumer Logic App
→ Decode body → Parse JSON → Process event
→ Azure Monitor alerts + runbooks
Overview

What this project solves

Many cloud integration platforms fail operationally because they are not properly monitored, documented or understood. This project simulates day-to-day platform support: checking API health, maintaining Logic Apps, monitoring Service Bus queues, responding to alerts and creating runbooks for handover.

The platform pattern

API-driven Dynamics 365 account sync with queue-based resilience.

The API request enters through Azure API Management. APIM forwards the request to a producer Logic App. The Logic App reads account records from Dynamics 365 / Dataverse and publishes account events to Service Bus. A consumer Logic App processes the queued messages.

  • APIM provides the controlled API gateway layer.
  • Logic Apps handle producer and consumer integration workflows.
  • Dynamics 365 / Dataverse provides the source business data.
  • Service Bus decouples the producer from the consumer.
  • Azure Monitor detects failed runs, backlog, dead-letter and gateway failures.
Key outcomes

Built, broken, fixed, monitored and documented.

This was not only a happy-path integration. The platform was intentionally tested through realistic operational failures: APIM 401 backend authentication, APIM 429 rate limiting, Service Bus backlog, disabled consumer, and a Parse JSON failure caused by encoded Service Bus content.

APIM 202 validatedAPIM 401 fixedAPIM 429 tested45-message backlog testedQueue drained to 0Parse JSON fixed5 runbooks created
Azure architecture

From API request to processed Service Bus event.

The platform is split into clear operational layers: API gateway, producer workflow, business data source, queue, consumer workflow and monitoring.

Logical components

  1. 1
    Azure API Management
    apim-integration-ops-oo
    Controlled gateway in front of the Logic App backend, applying rate limiting and backend routing.
    Gateway layerRate limitingPolicy troubleshooting
  2. 2
    Producer Logic App
    la-apim-dynamics-account-sync
    Receives APIM requests, lists Dataverse accounts and publishes account events to Service Bus.
  3. 3
    Dynamics 365 / Dataverse
    Accounts table
    Source business application data for the integration workflow.
  4. 4
    Service Bus Queue
    dynamics-apim-account-events
    Stores account event messages until the consumer processes them.
  5. 5
    Consumer Logic App + Azure Monitor
    la-consume-apim-account-events
    Receives messages, decodes ContentData, parses JSON and provides run history/alert evidence.

Operational flow

  1. 1
    APIM request returns 202
    API gateway forwards to producer and confirms the request was accepted.
  2. 2
    Messages published
    Producer reads Dynamics accounts and sends events into Service Bus.
  3. 3
    Backlog monitored
    If the consumer is disabled, active messages increase and Azure Monitor fires an alert.
  4. 4
    Consumer recovery
    Consumer Logic App is fixed, messages drain to zero and dead-letter stays zero.
  5. 5
    Runbooks document response
    Operational steps are documented for repeatable incident handling and handover.
Break/Fix incidents

Real operational failures investigated and fixed.

Each incident proves troubleshooting, root-cause isolation and recovery validation.

Incident 1

APIM 401 Unauthorized

APIM returned 401 when forwarding to the Logic App backend. The Logic App callback URL was tested directly with PowerShell and returned Accepted, proving the backend was healthy. The issue was isolated to APIM policy and fixed by passing the correct Logic App callback parameters.

401 fixedPowerShell direct testAPIM policy
Incident 2

APIM 429 rate limit

APIM returned 429 after more than 3 requests in 60 seconds. This proved the rate-limit policy was protecting the backend Logic App.

429 testedBackend protected
Incident 3

Service Bus backlog

The consumer Logic App was disabled. APIM and the producer stayed healthy, but messages accumulated in Service Bus. The queue reached 45 active messages and triggered the backlog alert.

45 active messagesAlert firedQueue recovered
Incident 4

Consumer Parse JSON failure

Runs failed at Parse JSON because Service Bus content was encoded. The fix was to decode the message body using base64ToString(triggerBody()?['ContentData']) before parsing.

Parse JSON fixedContentData decodedRun succeeded
Monitoring and alerting

Alerts built for gateway, workflow and queue health.

The lab includes monitoring across the main failure points of an integration platform.

Logic App producer

Failed producer runs

  • alert-la-apim-dynamics-account-sync-failed-runs.
  • Detects failed HTTP-triggered integration workflow runs.
Logic App consumer

Failed consumer runs

  • alert-la-consume-apim-account-events-failed-runs.
  • Detects consumer failures such as Parse JSON errors.
Service Bus

Backlog alert

  • alert-sb-dynamics-apim-account-events-backlog.
  • Fires when active messages exceed threshold.
Service Bus

Dead-letter alert

  • alert-sb-dynamics-apim-account-events-deadletter.
  • Fires when dead-letter messages are greater than 0.
APIM

Failed gateway requests

  • alert-apim-integration-ops-failed-gateway-requests.
  • Useful for APIM policy and backend authentication troubleshooting.
Demo – incident simulator

How the platform behaves during a downstream outage.

This safe browser-based simulator mirrors the real break/fix scenario from the lab.

Azure Integration Ops – Incident Simulator
APIM · Logic Apps · Service Bus · Azure Monitor · Runbook response
Safe simulation – no Azure changes
Incident control panel
Current test scenario
Consumer Logic App disabled → Service Bus backlog → Alert → Recovery
APIM status: Waiting
Active messages: 0
Dead-letter: 0
Alert: Not fired
Consumer: Enabled
Workflow progress
1
APIM request sent
API gateway receives account sync request.
2
Producer publishes messages
Logic App reads Dynamics accounts and sends events to Service Bus.
3
Consumer unavailable
Messages accumulate because downstream consumer is not processing.
4
Backlog alert fires
Azure Monitor detects active messages above threshold.
5
Consumer fixed
Logic App re-enabled and Parse JSON issue resolved.
6
Queue drains
Active messages return to 0 and dead-letter remains 0.
1
Detect

Azure Monitor detects active messages above threshold and fires the backlog alert.

2
Triage

Check APIM 202, producer runs, Service Bus depth and consumer run history.

3
Fix

Re-enable or repair the consumer. In this lab, Parse JSON required decoding Service Bus ContentData.

4
Validate

Confirm active messages return to 0, dead-letter remains 0 and consumer runs succeed.

Runbooks and documentation

Operational runbooks created for handover and support.

The project includes runbooks that explain symptoms, impact, common causes, triage steps, fix steps, validation criteria and evidence to capture.

Runbook 1

Service Bus Backlog Alert Response

Investigate active message buildup, confirm producer health, check consumer status and validate recovery.

Runbook 2

Logic App Consumer Parse JSON Failure

Inspect failed runs, identify encoded Service Bus content and fix Parse JSON using base64ToString.

Runbook 3

APIM 401 Unauthorized to Logic App

Isolate whether the problem is APIM policy/routing or the Logic App callback URL itself.

Runbook 4

APIM 429 Rate Limit

Confirm APIM rate limiting is expected gateway behaviour and validate backend protection.

Runbook 5

Service Bus Dead-letter Investigation

Inspect dead-letter messages, correlate with consumer failures and decide whether replay is safe.

Lessons learned

What this project proved.

This project mirrors cloud platform engineering support work: not just deploying services, but keeping them stable, monitored and documented.

APIM is more than an endpoint

APIM controls how clients reach backends. A 401 can be caused by backend authentication, missing query parameters, stale callback signatures or incorrect policy routing. Testing the backend directly helps isolate the fault.

Service Bus protects the platform during consumer outages

When the consumer was disabled, APIM and the producer still worked. Messages waited in Service Bus until the consumer recovered.

Successful queue drain does not always mean clean processing

The queue drained, but consumer runs initially failed at Parse JSON. Real operational validation means checking run history, failed actions, dead-letter count and end-to-end success.

Runbooks turn troubleshooting into repeatable operations

The final output included runbooks so another engineer can detect, triage, fix, validate and hand over platform issues consistently.